INFOVIA, RADIUS, PUSI, SYNFLOOD Y OTRAS ZARANDAJAS
Primero pedir disculpas a todos los sufridos lectores de este artφculo puesto que si muchos de los conceptos que en el se citan pueden resultar obvios, no se me ocurre otra manera de ir entrando en harina.
sLM╞ (Sociedad LiMitadisimµ).
á Que es infovia ?
Una red paralela a la Internet estrucucturada tambiΘn en protocolo TCP/IP, de tal forma que podemos acceder a INET (Internet) atraves de ella, es lo que Telef≤nica, la compa±ia que explota este producto, ha denominado INFOVIA. Para ello han tomado una Clase A de direcciones (10.0.0.0-10.255.255.255), direcciones estas reservadas para pruebas en INET, y han estructurado la red, de tal manera que si una de estas IP consiguiera acceder a INET, no causaria mayores problemas, dado que son direcciones no validas en INET, debemos de tener en cuenta que cuando accdemos a INET la direcci≤n que tenemos en ese momento es la que nuestro proveedor nos asigna, esto se consigue gracias al radius, verdadero artφfice de toda esta estructura paralela para ello al configurar nuestro acceso especificamos "login@proveedor", de tal manera que el CSIV (Centro Servidor de Infovia), sabe perfectamente a que CPI (Centro Proveedor de Infovia) tiene que lanzar la petici≤n de validaci≤n de usuario. En la actualidad existen 3 CSIV en Madrid, Barcelona y Valencia, con la particularidad que si cualquiera de ellos cayera, los otros 2 tomarian la carga, esto se debe a que desde la versi≤n de radius 2.0, entre otras mejoras los pools que asigna cada CPI son ·nicos, con lo que siempre podremos acceder a·n en el caso de que tengamos una IP fija.
á Que es radius ?
En su origen es un programa cliente servidor para verificaci≤n de usuarios remota, pero que ha sido adaptado por Telef≤nica para establcer la estrucutura de infovia. Las fuentes las podeis encontrar en "ftp.ascend.com", pero realmente estan tan modificadas que ya no tienen nada que ver con el estado actual del radius, por otra parte Telef≤nica lejos del espiritu de linux, (Es habitual en linux facilitar las fuentes del programa, y luego uno lo compila), no facilita las fuentes, pero esto es entrar ya en temas filos≤ficos, asφ que vayamos con lo que realmente nos interesa.
La maquina del ISP donde por defecto siempre se monta el server de radius es la "X.X.X.2", quedando la "X.X.X.1" reservada para el router del proveedor.
Normalmente el fichero donde se encuentran todas las claves de acceso de los usuarios es "/etc/raddb/usuarios_INFOVIA",á a no ser que a la hora de arrancar radius se haya indicado lo contrario.
"radiusd -d direc -u file"
Ahora el fichero de configuracion de usuarios es "/direc/file".
"radiusdll"
Igual que el radiusd pero el acceso lo comprueba de una base de datos dbm, la diferencia es que ahora cada vez que se produzca una alta, el proveedor debera de indexar el fichero de acceso, aunque para nuestros propositos el usuarios_INFOVIA sigue siendo el interesante. El problema es que para comprobar donde se encuentra el fichero de acceso no tenemos otro remedio que acceder a la maquina en cuesti≤n.
Finalmente el puerto por el que radius escucha las peticiones de autentificaci≤n de usuarios es el 1645.
*(1)*
Unas notas sobre PUSI
En los canales de hack aparte de las famosas boxes, siempre se acaba hablando de si es posible que Telef≤nica sepa el n·mero de telΘfono desde el que un usuario accede a infovia, pues bien se±ores la respuesta es SI en la mayor parte de los casos, para ello utilizan la se±alizaci≤n por canal com·n.
CCS (Chanel Common Signaling- Se±alizaci≤n por canal comun).
En se±alizaci≤n PUSI se envia la informaci≤n de muchos enlaces por el canal 16 de un MIC (Modulacion de Impulsos Codificados), no como se venia haciendo hasta el momento en las centrales analogicas, es decir mandar la se±alizaci≤n de todo el MIC por su canal 16 (CAS, Se±alizaci≤n por canal asociado). Para ello la se±alizaci≤n va en forma de paquetes, y desde la ·ltima revisi≤n de software de los modulos digitales, se ha implementado la facilidad de mandar el n·mero A (Abonado llamante). En la actualidad todas las centrales digitales implementan esta facilidad, ahora bien, la informaci≤n del numero llamante solo la recibe infovia, no pasando este dato al CPI, esto en la versi≤n 2.0 de radius por que anteriormente si que se facilitaba este dato al CPI.
*(2)*
áááááááááááááá Log de una llamada se±alizaci≤n PUSI
áááááááááááááá Red p·blica a la que se conecta el usuario local.
-0001000 Descripci≤n de progreso:
áááááááááááááá En este momento se encuentra disponible una informaci≤n o
áááááááááááááá una secuencia adecuada dentro de banda.
áááááááá 28114c494245524143494f4e204e4f524d414c
áááááááá * E.I. VISUALIZACION: 28
áááááááá Longitud: 11
áááááááá Informaci≤n de visualizaci≤n:
áááááááááááááá LIBERACION NORMAL
RECIBIDO:08019a4d
00001000 Discriminador de protocolo: 08
áááááááááááááá Protocolo Q.931.
áááááááá Valor de referencia de llamada: 019a
áááááááááááááá 26.
ááááááááá LIBERACION (REL)á <-----
ENVIADO :08011a5a
00001000 Discriminador de protocolo: 08
áááááááááááááá Protocolo Q.931.
áááááááá Valor de referencia de llamada: 011a
áááááááááááááá 26.
ááááááááá LIBERACION COMPLETA (REL COM)á ----->
--------------------------------------------------------------------------------ááááááááááááááá /* Fin del log de la llamada */ááááááááááááááá /* ------------------------- */
Este ataque es del tipo denial of service (DOS), y funciona debido a la propia implementaci≤n del protocolo TCP/IP. Al ser TCP/IP un protocolo orientado a la conexi≤n, si dos hosts quieren intercambiar datos, primero deben de establecer la conexi≤n entre ellos, para ello TCP lleva acabo un proceso de 3 tiempos conocido como "3-way handshake", por ejemplo si la maquina A estß ejecutando un cliente y quiere conectar con el server B, el proceso sera el siguiente:
ááááááááááááááááááááááá 1-á A ----- SYN ----- > B
ááááááááááááááááááááááá 2-á A <-- SYN/ACK ----á B
ááááááááááááááááááááááá 3-á A ----- ACK ------> B
(1) El cliente (A) le dice al servidor (B) que quiere conectarse, para ello
activa el flag SYN, ajusta el campo de numero de secuencia en la cabecera TCP
con su ISN (numero inicial de secuencia).
(2) El server responde con su ISN y un ACKnowledgement (Reconocido).
(3) El cliente ahora ACK el ISN del server.
Ahora una vez establecida la conexi≤n, podrßn intercambiar datos.
Flags de control de TCP
SYN: N·mero de secuencia de sincronizaci≤n.
ááá Solo se utiliza en el proceso de establecimiento de la conexi≤n, le
ááá indica al receptor que compruebe el campo de n·mero de secuencia y
ááá anote su valor en el ISN, para ello TCP posee un contador de 32 bits.
ACK: Acknowledgement (Reconocimiento).
ááá Este flag almacena el n·mero de secuencia del siguiente paquete esperado.
RST: Reset.
ááá Destruye la conexi≤n.
URG: Urgente.
ááá Indica que el puntero de urgencia es valido.Por ejemplo si en una conexi≤n
ááá telnet el cliente pulsa ctrl-C, esto se considera urgente y el flag es
ááá activado.
PSH: Push.
ááá El receptor no pondrß en cola los datos del paquete, y se los pasara a la
ááá aplicaci≤n lo antes posible, este flag siempre estß activo en conexiones
ááá interactivas como telnet.
FIN: Finish.
ááá Se ha finalizado de enviar datos, aunque se pueden seguir reciviendo.
Para garantizar accesos simultaneos al modulo TCP, el protocolo nos ofrece un interface de usuario llamado "port", los puertos son usados por el kernel para identificar los procesos de red, junto con la IP suministran un punto final de conexi≤n de red, en realidad en cualquier momento todas las conexiones de internet quedan perfectamente definidas por la direcci≤n IP y puerto del cliente, y direcci≤n IP y puerto del servidor.
Estructuras de memoria en una conexi≤n TCP
Dependiendo del sistema operativo, las estructuras difieren, veamos las de linux.
Socket (socket{}): Almacena informaci≤n relativa a la comunicaci≤n local como:
ááááááááááááááááá protocolo usado,informacion de direcciones, colas de conexion,
ááááááááááááááááá buffers, flags, etc ...
Sock (sock{})ááá : informaci≤n especφfica del protocolo.
Sk (sk_buff{})áá : Informaci≤n mas especφfica del protocolo incluyendo la
ááááááááááááááááá informaci≤n de cabecera de paquete, contiene tambien un
ááááááááááááááááá sock{}.
Backlogááááááááá : Son unas estructuras de memoria muy grandes.Cada vez que un
áááááááááááááááááá server recive una petici≤n SYN de un cliente debe de hacerse
áááááááááááááááááá sitio en memoria, de tal forma que si no existiese un n·mero
áááááááááááááááááá maximo de conexiones pendientes de verificaci≤n, esta
áááááááááááááááááá situaci≤n nos podria llevar a dejar al server sin memoria
áááááááááááááááááá disponible, para evitar esto el server dispone de un
áááááááááááááááááá mecanismo de control en el que se especifica el lφmite de
áááááááááááááááááá peticiones de conexi≤n que un socket TCP puede tener
áááááááááááááááááá abiertas sin llegar a establecer la conexi≤n , este lφmite
áááááááááááááááááá se conoce como "Backlog", se±alar como aquφ se encuentran
áááááááááááááááááá tanto las peticiones de conexi≤n (3-way handshake), como
áááááááááááááááááá las conexiones completadas que a·n no han sido aceptadas
áááááááááááááááááá por la aplicaci≤n.
áááááááááááááááááá Este "Backlog" no es n·mero muy grande, y aunque nos
áááááááááááááááááá parezca raro, tampoco tiene por que serlo dada la rapidez
áááááááááááááááááá que TCP tiene a la hora de establecer conexiones, si
áááááááááááááááááá recibimos una petici≤n de un cliente y la cola de "Backlog"
áááááááááááááááááá estß llena, es mßs que seguro que al retransmitir el cliente
áááááááááááááááááá la petici≤n de conexi≤n ya tendremos de nuevo sitio en la
áááááááááááááááááá cola de backlog, en suma se trata pues de un proceso muy
áááááááááááááááááá rapido.Existe otro parametro dentro del backlog conocido
áááááááááááááááááá como gracia "grace", de tal forma que si se alcanza el
áááááááááááááááááá mßximo n·mero de peticiones de conexi≤n el sistema dispone
áááááááááááááááááá de un margen de gracia para nuevas conexiones.
áááááááááááááááááá Valores relaes de backlog en sistemas operativos:
áááááááááááááááááá Sistema Operativoááááááá Backlogáááá Grace
Una conexi≤n TCP se inicia cuando un cliente lanza una petici≤n de conexi≤n a un server, para ello el cliente manda el flag SYN activado en la cabecera TCP, al llegar este paquete a un socket receptivo en el server y una vez demultiplexado el paquete, obtenidas las direcciones de la cabecera TCP y comprobado que el checksum es correcto, se inicializa un temporizador de 75 segundos pasando la conexi≤n a modo SYN_RCVD (SYN recibido), para ello el server contesta a esta petici≤n con SYN/ACK, y son creadas todas las extructuras de memoria correspondientes para la nueva conexi≤n. ¿ Pero que ocurre si la direcci≤n IP obtenida del cliente no es valida, es decir si el cliente esta mandando una IP que no es la suya (Spoofing) y ademas esta no esta acesible en internet en el momento de la conexi≤n ?, en este caso el proceso "3-way handshake" nunca se llegara a completar con lo que el server esperarß los 75 segundos del temporizador de conexi≤n antes de reinizializarse, puesto que estß mandando paquetes SYN/ACK a una direcci≤n NO en red de la que nunca recibirß respuesta , ¿ Y si ademas mandamos varios paquetes de conexi≤n de forma que alcancemos el lφmite de backlog del server ?, ahora tenemos un puerto "FLOODEADO" si se me permite la expresi≤n, esto es, el puerto en cuesti≤n no puede aceptar nuevas conexiones por que estß intentando resolver las peticiones tiene en la cola de backlog, y ademas solo se van a resolver cuando temporicen los 75 segundos.
Caracteristicas
Este tipo de ataque requiere muy poca cantidad de ancho de banda para llevarse a cabo, puesto que en realidad la cantidad de datos que necesitamos enviar para floodear un puerto es muy peque±a, simplemente nos bastarß con mandar 6 paquetes por minuto para tener un puerto totalmente parado.
*(4)*
Apendice (1) En el apartado de radius e infovia no me he extendido, puesto que el ßrticulo corria el riesgo de hacerse excesivamente largo.
(2) Propongo al avezado lector una practica de agudeza.En el log de llamada con se±alizaci≤n PUSI, el numero del llamante es la fecha de terminaci≤n de este artφculo, el n·mero del telΘfono llamado ha sido omitido, ¿Sois capaces de descubrirlo? :-)
(3) Tambien he incluido un log de lo que recibe un CPI, para terminar con el bulo de que el proveedor de internet conoce el n·mero de teléfono del usuario, aunque tener claro que si vuestra linea es digital infovia si que lo conoce. En las versiones anteriores de radius este dato si que era suministrado al proveedor.
(4) En un principio pense en poner las fuentes de un prog para hacer spoofing, synflooding, pero teniendo en cuenta de que nunca se sabe en que manos puede caer lo he omitido.
Por ·ltimo quiero dar las gracias a "La llave maestra" por los buenos momentos que me hizo pasar mientras la ojeaba :-))))
En proximos n·meros TCL/TK un interface para el firewall, modulaci≤n de espectro expandido (Enlaces de 2 Mg por radio), acceso a INET por radio, validaci≤n remota de usuarios para los routers, o lo que ustedes gusten si vuelven a darme otra oportunidad. ;-)
